@jcoux @gurneyalex I'm not so much in favor of this as it could lead to duplicate entries (e.g.: two lines for sale-workflow and a branch on it if contributor added it to make PR green).

Moreover, if we do so, we should generalize it.

Just one remark there, this will be useful only in case of manual merging, github doesn't do it automatically. Not sure about the OCA bot. Maybe something to define on the OCA bot?

We could sort this out with a little more complexe merge policy. As merge policy could be extended with scripts. We would need something like add all, sort and keep unique.

@sbidoul any opinion on this, do you think it's the role of the ocabot try to make the rebase on it's own? Thus needing us to give it strong directives?
Personally I would say that as long as we can identify something that will be repeated often and for which we identify the workflow/boundaries we want to automate it.

The ocabot merge strategy could be improved to cope with that, but...

I still think oca_dependencies.txt is redundant, as well as requirements.txt because all dependencies are expressed in the manifests. And we can easily get rid of both of them by installing addons to test with pip: OCA/maintainer-quality-tools#343

So I'd rather address the root cause of the issue (redundant files) than add automation complexity to cope with them.

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

@yvaucher FYI, installation of dependencies is now implemented in MQT. It is opt-in: to activate it you need to set MQT_DEP=PIP in .travis.yml environment variables.